Packet flow management for quality of service (qos) flows in a private 5g network

ABSTRACT

A user plane function (UPF) node may receive a packet for traffic associated with a user equipment (UE). During packet classification, the UPF node may identify that a packet filter for the packet is not found in a packet filter set of an existing Quality of Service (QoS) Flow. In response, the UPF node may configure the packet filter in the packet filter set of the QoS Flow based on a flow tuple of the packet. The UPF node may send, to a control plane function node, a message which indicates a request for adding the flow tuple to the QoS Flow. The message may be for triggering communication of a message which indicates a session modification command for receipt by the UE, for adding an uplink packet filter that is based on the flow tuple for the QoS Flow.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.17/332,264, filed May 27, 2021, the entirety of which is incorporatedherein by reference.

TECHNICAL FIELD

The present disclosure relates to telecommunications, and in particular,to techniques and mechanisms for packet flow management for establishedQuality of Service (QoS) flows in a mobile network, such as anenterprise private Third Generation Partnership Project (3GPP) network.

BACKGROUND

An enterprise network deployment may be or include a Fifth Generation(5G) network for “private 5G.” In such enterprise deployments thatinvolve mission-critical devices, Internet of Things (IoT) devices, androbotics, key considerations are reliability, low-latency, andapplication-specific Quality of Service (QoS) treatment.

Private 5G adopts the concept of a QoS Flow from the basic 5G System(5GS) architecture defined in Third Generation Partnership Project(3GPP) standards. QoS Flows start at a User Plane Function (UPF) andextend to a gNodeB (gNB), and are mapped to radio bearers/QoS Flows atthe gNB. Sessions of the UPF are managed by a Session ManagementFunction (SMF) over an N4 interface using a Packet Forwarding ControlProtocol (PFCP).

A QoS Flow represents a particular QoS classification and treatment onan application or Internet Protocol (IP) flow basis. A 5G QoS Identifier(5QI) is used to identify a specific QoS forwarding behavior for a QoSFlow (similar to a QoS Class Identifier “QCI” in an Long-Term Evolution“LTE” network). A QoS Flow may be associated with a Guaranteed Bit Rate(GBR), a Guaranteed Flow Bit Rate (GFBR), a Maximum Bit Rate (MBR), or aPacket Delay Budget (PDB), as examples. A GBR or GFBR bearer guaranteesthat a specific minimum bit rate is always available on that bearer.

For 5G communications, the bandwidth requirement is typically quitelarge. At the core network or UPF, system resources may be very limited.There are GBR QoS Flows in 5G that require high bandwidth, low latencyand high throughput. Such types of resources are limited in a private 5Gnetwork. For example, an enterprise system may only be able to provideGBRs for two-hundred (200) active QoS flows at given time; how manyactive sessions/QoS flows are present at a given instant will depend onthe actual deployment model.

As is apparent, many types of radio bearers/QoS flows may be consideredto be premium resources and, accordingly, they should be monitored andutilized wisely. Overload or congestion in the network may result inundesirable packet drops and QoS degradation. In some cases, the UPF maybe unable to guarantee the GBR, GFBR, or PDB for QoS Flows due to suchcongestion and overload.

To monitor and utilize resources wisely, the UPF may actively manage andmonitor QoS Flows to keep active only those QoS Flows which have trafficactivity, deleting QoS Flows that are detected to have trafficinactivity and re-creating QoS Flows having newly-detected activity.These techniques for creating or re-creating a QoS Flow include theidentification and use of a single 5-tuple packet filter according tothe first detected packet. However, a QoS Flow may be used for manydifferent IP traffic streams associated with multiple different5-tuples. These different IP traffic streams may be associated with thesame or different applications. The procedures for active management ofQoS Flows would need further consideration for classifying trafficassociated with any or all different IP traffic streams associated withthe same QoS Flow.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the present disclosure can be understood by those of ordinaryskill in the art, a more detailed description may be had by reference toaspects of some illustrative implementations, some of which are shown inthe accompanying drawings.

FIG. 1A is an illustrative representation of a basic networkarchitecture of an enterprise private Third Generation PartnershipProject (3GPP) network, which is (more specifically) a private FifthGeneration (5G) network, which may include a user plane function (UFP)and a control plane function which may be or include a sessionmanagement function (SMF);

FIG. 1B shows the network architecture of the private 5G network of FIG.1A as a simplified, schematic block diagram;

FIG. 2A is a table for representing a mapping of associations betweenapplications, data networks, and business intents of the private 5Gnetwork, which may be provided from a network controller to the controlplane function of the private 5G network;

FIG. 2B is a table for representing a mapping of associations between aplurality of application identifiers (IDs)/names associated withapplications and a plurality of 5G Quality of Service (QoS) Identifiers(5QIs) associated with QoS policies;

FIG. 2C is a more simplified table for representing a mapping ofassociations between a plurality of application IDs/names associatedwith applications and a plurality of 5QIs associated with QoS policies;

FIG. 3 is a call flow diagram for describing a call flow for QoSresource management for optimizing use of QoS resources in a mobilenetwork (e.g. with use of a UPF-triggered QoS Flow creation procedure),which involve techniques upon which packet flow management of thepresent disclosure may be built upon;

FIG. 4 is a call flow diagram for describing a call flow for QoSresource management for optimizing use of QoS resources in a mobilenetwork (e.g. with use of a UPF-triggered QoS Flow deletion procedure),which involve techniques upon which packet flow management of thepresent disclosure may be built upon;

FIG. 5 is a flowchart for describing a method of packet flow managementfor existing QoS Flows in a mobile network, which includes a packet flowand filter addition to an existing QoS Flow according to someimplementations of the present disclosure, which may be performed by auser plane function node of the mobile network;

FIG. 6 is a flowchart for describing a method of packet flow managementfor existing QoS Flows in a mobile network, which includes a packet flowand filter addition to an existing QoS Flow according to someimplementations of the present disclosure, which may be performed by acontrol plane function node of the mobile network;

FIG. 7 is a call flow diagram for describing a call flow for packet flowmanagement for existing QoS Flows in a mobile network, including apacket flow and filter addition to an existing QoS Flow according tosome implementations of the present disclosure;

FIG. 8 is a table having a list of information elements (IEs) which maybe utilized in a message which indicates a request for adding a flowtuple to an existing QoS Flow for the methods described in relation toFIGS. 5-7 according to some implementations;

FIG. 9 is a table having a list of IEs which may be utilized in amessage which indicates a response to the request for adding a flowtuple from an existing QoS Flow for the methods described in relation toFIGS. 5-7 according to some implementations;

FIG. 10 is a flowchart for describing a method of packet flow managementfor existing QoS Flows in a mobile network, including a packet flow andfilter removal from an existing QoS Flow according to someimplementations of the present disclosure, which may be performed by auser plane function node of the mobile network;

FIG. 11 is a flowchart for describing a method of packet flow managementfor existing QoS Flows in a mobile network, including a packet flow andfilter removal from an existing QoS Flow according to someimplementations of the present disclosure, which may be performed by acontrol plane function node of the mobile network;

FIG. 12 is a call flow diagram for describing a call flow for packetflow management for existing QoS Flows in a mobile network, including apacket flow and filter removal from an existing QoS Flow according tosome implementations of the present disclosure;

FIG. 13 is a table having a list of IEs which may be utilized in amessage which indicates a request for removing a flow tuple to anexisting QoS Flow for the methods described in relation to FIGS. 10-12according to some implementations;

FIG. 14 is a table having a list of IEs which may be utilized in amessage which indicates a response to the request for removing a flowtuple from an existing QoS Flow for the methods described in relation toFIGS. 10-12 according to some implementations; and

FIG. 15 illustrates a hardware block diagram of a computing device thatmay perform functions associated with operations discussed herein.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Numerous details are described in order to provide a thoroughunderstanding of the example implementations shown in the drawings.However, the drawings merely show some example aspects of the presentdisclosure and are therefore not to be considered limiting. Those ofordinary skill in the art will appreciate that other effective aspectsand/or variants do not include all of the specific details describedherein. Moreover, well-known systems, methods, components, devices andcircuits have not been described in exhaustive detail so as not toobscure more pertinent aspects of the example implementations describedherein.

Overview

Techniques and mechanisms for packet flow management for existingQuality of Service (QoS) Flows in a mobile network are described herein.The mobile network may be or include a Third Generation PartnershipProject (3GPP) mobile network, such as a 3GPP Fifth Generation (5G)network or an enterprise private 3GPP 5G network.

In one illustrative example, a packet flow and filter may be added to anexisting QoS Flow according to some implementations of the presentdisclosure. A user plane function node (e.g. having a user planefunction or “UPF”) may receive a packet for traffic associated with auser equipment (UE). The user plane function node may identify that apacket filter for the packet is not found in a packet filter set of anexisting QoS Flow. Based on the identifying, the user plane functionnode may configure the packet filter in the packet filter set of theexisting QoS Flow based on a flow tuple of the packet. The packet filterbased on the flow tuple may be utilized for packet classification of apacket flow associated with the UE. In addition, the user plane functionnode may send, to a control plane function node, a message whichindicates a request for adding the flow tuple to the existing QoS Flow.The message may be used for triggering communication of a message whichindicates a session modification command for receipt by the UE, foradding an uplink packet filter that is based on the flow tuple for theexisting QoS Flow. The message which indicate the request may includethe flow tuple of the packet associated with the packet flow, a QoS FlowIdentifier (QFI) of the existing QoS Flow, and a Packet Detection Rule(PDR) ID of a PDR associated with the packet filter set. The user planefunction node may receive, from the control plane function node, amessage which indicates a response to the request for adding the flowtuple to the existing QoS Flow.

In some implementations, if the packet filter for the packet is notfound in the packet filter set, but the user plane function nodeidentifies that packet classification for the packet is based on anaccess control list (ACL) or a Differentiated Services Control Point(DSCP) (e.g. for traditional enterprise QoS/policy control), then theuser plane function node may refrain from performing the steps ofconfiguring and sending the message which indicates the request.

In a corresponding method to the above-described method, a control planefunction node (e.g. having an SMF, or both an SMF and an AMF) mayreceive, from a user plane function node (e.g. having a UPF), a messagewhich indicates a request for adding a flow tuple to an existing QoSFlow for traffic associated with a UE. This request may be received inresponse to the user plane function node identifying that a packetfilter for a detected packet is not found in a packet filter set of anexisting QoS Flow. The message may indicate the flow tuple of thedetected packet of a packet flow, a QFI of the existing QoS Flow, and aPDR ID of a PDR associated with the packet filter set. Based onreceiving the message which indicates the request, the control planefunction node may communicate a message which indicates a sessionmodification command for receipt by the UE, for adding an uplink packetfilter that is based on the flow tuple for the existing QoS Flow. Thecontrol plane function node may send, from the user plane function node,a message which indicates a response to the request for adding the flowtuple to the existing QoS Flow.

In another illustrative example, a packet flow and filter may be removedfrom an existing QoS Flow according to some implementations of thepresent disclosure. A user plane function node (e.g. having a UPF) mayidentify that a limit on a number of packet filters of a packet filterset of the existing QoS Flow has been reached. Alternatively, the userplane function node may identify that a measured time period of trafficinactivity for a packet flow of the existing QoS Flow has been reached.Based on the identifying, the user plane function node may remove apacket filter in the packet filter set of the existing QoS Flow, wherethe packet filter is based on a flow tuple and utilized for packetclassification of the packet flow. The user plane function node maysend, to a control plane function node (e.g. having an SMF, or both anSMF and an AMF, a message which indicates a request for removing theflow tuple from the existing QoS Flow. The message may be used fortriggering communication of a message which indicates a sessionmodification command for receipt by the UE, for removal of an uplinkpacket filter that is based on the flow tuple of the existing QoS Flow.The message which indicates the request may include the flow tuple ofthe packet associated with the packet flow, a QFI of the existing QoSFlow, and a PDR ID of a PDR associated with the packet filter set. Theuser plane function node may receive, from the control plane functionnode, a message which indicates a response to the request for removingthe flow tuple from the existing QoS Flow.

In a corresponding method to the above-described method, a control planefunction node (e.g. having the SMF, or both the SMF and the AMF) mayreceive, from a user plane function node (e.g. having the UPF), amessage which indicates a request for removing a flow tuple from theexisting QoS Flow. This request may be received in response to the userplane function node identifying that a limit on a number of packetfilters of the packet filter set of the existing QoS Flow has beenreached. Alternatively, this request may be received in response toidentifying that a measured time period of traffic inactivity for apacket flow of the existing QoS Flow has been reached. The message mayindicate the flow tuple associated with a packet flow, the QFI of theexisting QoS Flow, and a PDR ID of a PDR associated with a packet filterset of the existing QoS Flow. Based on receiving the message whichindicates the request, the control plane function node may communicate amessage which indicates a session modification command for receipt bythe UE, for removal of an uplink packet filter that is based on the flowtuple for the existing QoS Flow. The control plane function node maysend, to the user plane function node, a message which indicates aresponse to the request for removing the flow tuple from the existingQoS Flow.

More detailed and alternative techniques and implementations areprovided herein as described below.

Example Embodiments

As described earlier in the Background section, an enterprise networkdeployment may be or include a Third Generation Partnership Project(3GPP) defined Fifth Generation (5G) network for “private 5G.” In suchenterprise deployments that involve mission-critical devices, Internetof Things (IoT) devices, and robotics, key considerations arereliability, low-latency, and application-specific Quality of Service(QoS) treatment.

To illustrate, FIG. 1A is an illustrative representation of a networkarchitecture 100A of an enterprise private 3GPP network for anenterprise, which is, more specifically, a private network. Relatedly,FIG. 1B shows a network architecture 100B of the private 5G network ofFIG. 1A as a simplified, schematic block diagram.

The private 5G network may utilize the network architecture 100A/100B inFIGS. 1A-1B to facilitate communications for a plurality of clients 120or user equipment (UEs), such as a UE 102. UE 102 may be any suitabletype of device, such as a cellular telephone, a smart phone, a tabletdevice, an IoT device, a Machine-to-Machine (M2M) device, a roboticsdevice, and a sensor, to name but a few. UE 102 may obtain access to theprivate 5G network via a radio access network (RAN) which may have oneor more base stations or gNodeBs (gNB s) 122, such as a gNB 104. A userplane function (UPF) 106 may be used to carry traffic for an applicationfor UE 102. For example, UPF 106 may carry uplink (UL) and downlink (DL)traffic between UE 102 operating in the private 5G network and a network112, such as the Internet.

A control plane function(s) 108 of a control plane may be utilized inthe private 5G network for access and mobility management, sessionmanagement, and/or policy management and control, etc., for UEs. Inparticular, control plane function 108 may include an Access andMobility Management Function (AMF) 124 and a Session Management Function(SMF) 126, as well as other 3GPP 5G System (5GS) defined functions (someor all of which may be enabled). AMF 124 and SMF 126 (as well as other5GS-defined functions) may be implemented as separate functions orcomponents, or alternatively provided together as an integratedfunctionality (in whole or in part) and/or co-located at the same nodeor component. A session at UPF 106 may be managed by SMF 126 over an N4interface using a Packet Forwarding Control Protocol (PFCP). In someimplementations, control plane function 108 is provided locally in theprivate 5G network. In other implementations, control plane function 108is provided as part of a cloud infrastructure.

Operation, functionality, and protocols utilized in the private 5Gnetwork may at least generally conform to 3GPP standards for 5G (e.g.3GPP Technical Specifications or “TS” 23.501 and 23.502), except whereadapted and described herein according to the present disclosure. Aplurality of interfaces and/or reference points N1, N2, N3, N4, and N6shown in FIGS. 1A-1B (and others) may represent the communicationsand/or protocols between each of the entities, as is known by therelevant (evolving) standards documents.

A network controller 110 may also be provided for managing the private5G network. More particularly, network controller 110 may be provided inthe private 5G network for managing and controlling policy andconfiguration in the private 5G network. In some implementations,network controller 110 is provided locally in the private 5G network. Inother implementations, network controller 110 is provided as part of acloud infrastructure. In one example, the cloud infrastructure havingnetwork controller 110 may be referred to as a cloud manager or amanagement cloud.

In some implementations, network controller 110 in the cloudinfrastructure is operative to provide management and control overpolicy and configuration according to intent-based networking. Themotivation of intent-based networking is to enable a user to describe inplain language what he or she wants to accomplish (e.g. the user'sintent) and have the network translate the user's objective intoconfiguration and policy changes that are automatically propagatedacross a heterogeneous computing environment. An intent-based networkoperates to abstract network complexity, automate much of the work ofprovisioning and managing the network typically handled by a networkadministrator, and assure secure operation and optimal performance ofthe network. In some implementations, network controller 110 in thecloud infrastructure may be or include a Cisco Digital NetworkArchitecture (Cisco DNA™).

Private 5G adopts the concept of a QoS Flow from the standard 5GSarchitecture. A QoS Flow starts at UPF 106 and extends to gNB 104, whereit is mapped to a radio bearer/QoS Flow to UE 102. Each QoS Flow isassociated with a particular QoS classification and treatment on anInternet Protocol (IP) or application flow basis. A 5G QoS Identifier(5QI) is used to identify a specific QoS forwarding behavior for a QoSFlow. A QoS Flow may be associated with a Guaranteed Bit Rate (GBR), aGuaranteed Flow Bit Rate (GFBR), a Maximum Bit Rate (MBR), or a PacketDelay Budget (PDB), as examples. A GBR or GFBR bearer guarantees that aspecific minimum bit rate is always available on that bearer.

For 5G communications, the bandwidth requirement is typically quitelarge. There are GBR QoS Flows in 5G that require high bandwidth, lowlatency and high throughput. Such GBR-type QoS Flows and associatedradio bearers may be considered to be premium resources, especially in alimited private network. Unfortunately, congestion or overload in thenetwork may result in undesirable packet drops and QoS degradation. Insome cases, UPF 106 may be unable to guarantee the GBR, GFBR or PDB forQoS Flows due to congestion and overload.

To explain further, each private 5G network or system of an enterprisemay have its own system level capacity. Consider a system where a datarate requirement per QoS Flow is 100 megabits per second (MBPS) and anoverall system limit is 20 gigabits per second (GBPS). In this case, thesystem can provide GBRs for two-hundred (200) active QoS Flows at agiven time. However, the number of active sessions/QoS Flows present ata given instant will depend on the deployment model. Admission controlat the SMF is unable to solve the present issues, as there are clientsthat require a high bandwidth and, if limitations are configuredaccording to admission control, the system may have scaling challenges.In one example environment, the system level capacity may be 64,000(64K) where two-hundred (200) active sessions may be present at a giventime, but the number can always be exceeded if the number of activesessions/QoS Flows exceeds the estimate.

According to some implementations, techniques and mechanisms of thepresent disclosure may be provided together with or built upon existingprocedures for QoS resource management, for example, a “UPF-triggeredQoS Flow creation procedure” and/or a “UPF-triggered QoS Flow deletionprocedure” for optimizing use of QoS resources in a mobile network. Inthese procedures, a UPF may keep an active monitoring of QoS Flows (e.g.those associated with one of a GBR, GFBR, or PDB), keeping active onlythose QoS Flows which have traffic activity, and deleting QoS Flows thatare detected to have traffic inactivity. For example, the UPF maydetermine that a measured time period of traffic inactivity for adedicated QoS Flow is outside a limit set by a time period threshold,and send to the SMF a request for deleting the dedicated QoS Flow basedon the determining. When traffic is again received for an applicationfor a UE for which no current dedicated QoS flow exists, the UPF maysend a request for creating a dedicated QoS Flow for the traffic withthe appropriate QoS.

What may be utilized in the above-mentioned procedures is a mapping ofstored associations between a plurality of application identifiers (IDs)and/or names of applications (e.g. “5G applications”) and 5QIs and/orcorresponding QoS profiles (as well as other relevant information, ifand as needed). This mapping may be stored at and/or used by the controlplane function (e.g. the SMF). To that end, with reference back to FIGS.1A, it is illustrated that information for 5G applications may be inputto (e.g. by a network administrator) and sent from network controller110 to control plane function 108 for use with the private 5G network.The information may include a mapping 130 of stored associations betweenapplications, data networks, and business intents of the private 5Gnetwork. Control plane function 108 may obtain the information thatincludes mapping 130, and use this information to build or generate amapping 132 of stored associations between a plurality of applicationIDs/names associated with the applications and a plurality of 5QIsassociated with QoS profiles.

To better illustrate and explain, FIG. 2A is a table 200A forrepresenting the mapping 130 of stored associations betweenapplications, data networks, and business intents of the private 5Gnetwork. Mapping 130 may be provided from network controller 110 tocontrol plane function 108 for use with the private 5G network (see FIG.1A). In this example, mapping 130 may associate applications for variousservices with Data Network Names (DNN) and particular intents. Asindicated, the various example services associated with the applicationsmay include Session Initiation Protocol (SIP), Real-time TransferProtocol (RTP), Telepresence, WebEx, Jabber, Facetime, WhatsApp, andYouTube. The business intents may include whether or not the service isenterprise relevant or enterprise irrelevant.

FIG. 2B is a table 200B for representing the mapping 132 of storedassociations between a plurality of application IDs/names associatedwith the applications and a plurality of 5QIs (as well as additionalinformation). Each one of the plurality of 5QIs may be associated with arespective one of a plurality of different QoS profiles. Mapping 132 oftable 200B in FIG. 2B may be stored at control plane function 108 foruse with the private 5G network (see FIG. 1A). In FIG. 2B, each entryfor an application ID/name (e.g. SIP, RTP, Telepresence, WebEx, Jabber,Facetime, WhatsApp, or YouTube) may be associated with a unique 5QI andcorrespondingly a unique QoS profile, associated with a type of service(e.g. voice, conversational video, or buffered video), a resource type(e.g. GBR or non-GBR), a default priority level (e.g. 20, 40, or 60), aPDB (e.g. 100 ms, 150 ms, or 300 ms), and a category of service(conversational voice, conversational video, or video—bufferedstreaming).

FIG. 2C is a more simplified table 200C for representing the mapping 132of stored associations between a plurality of application IDs/names(e.g. ID 1, ID 2, and ID 3 etc.) associated with applications and aplurality of 5QIs (e.g. 1, 2, 6, etc.) associated with the QoS profiles.Mapping 132 in table 200C of FIG. 2C may be stored at control planefunction 108 for use with the private 5G network (see FIG. 1A). Again,each of the plurality of 5QIs (e.g. 1, 2, 6, etc.) may be associatedwith a respective one of a plurality of different QoS profiles (e.g. QoSprofile 1, QoS profile 2, QoS profile 3, etc.).

Each QoS profile and flow may be associated with a QoS Flow Identifier(QFI). A QoS profile may be or include a plurality of QoS parameters: a5QI; an Allocation and Retention Priority (ARP); for each Non-GBR QoSFlow, a Reflective QoS Attribute (RQA); for each GBR QoS Flow, a GFBR(for UL and DL), and a Maximum Flow Bit Rate (MFBR) (for UL and DL); inthe case of a GBR QoS Flow, a notification control, and a Maximum PacketLoss Rate (for UL and DL).

As mentioned above, in some implementations, techniques and mechanismsof the present disclosure may be provided together with or built uponexisting procedures for QoS resource management, for example, a“UPF-triggered QoS Flow creation procedure” and/or a “UPF-triggered QoSFlow deletion procedure” for optimizing use of QoS resources in a mobilenetwork. These procedures are now described in relation to FIG. 3 (i.e.a UPF-triggered QoS Flow creation procedure) and FIG. 4 (i.e. aUPF-triggered QoS Flow deletion procedure).

FIG. 3 is a call flow diagram 300 for describing a call flow for QoSresource management for optimizing use of QoS resources in a mobilenetwork (e.g. the enterprise private 3GPP based network of FIGS. 1A-1B)according to some implementations of the present disclosure. In someimplementations, the call flow of FIG. 3 may be and/or be referred to asa UPF-triggered QoS Flow creation procedure.

In general, UPF 106 operates to forward traffic for applications for UEsoperating in a mobile network. Initially, however, no current dedicatedQoS Flow is established for traffic for an application for a particularUE (i.e. UE 102) which operates in the mobile network. Sometime duringoperation, UPF 106 may detect traffic for the application for UE 102 forwhich no current dedicated QoS Flow is established (step 304 of FIG. 3). Again, such detection of traffic may be (e.g. only) for thoseapplications that SMF 126 configures or provisions at UPF 106 (e.g.pre-configured application identifiers for enterprise-aware or approvedapplications). UPF 106 may forward this (e.g. initial or startup)traffic in a default QoS Flow of UE 102 (e.g. a previously-establisheddefault QoS Flow). In response to the detection of the traffic, UPF 106may send, to SMF 126, a message which indicates a request for creating adedicated QoS Flow for traffic for the application for UE 102 (step 306of FIG. 3 ). The message may include flow metadata (e.g. n-tuple flowmetadata) and an application identifier obtained in detecting theinitial traffic. The detection at UPF 106 may involve the use of DPI orthe like. SMF 126 may receive this message and send, to UPF 106, amessage which indicates a response to creating the dedicated QoS Flow(step 308 of FIG. 3 ). In some implementations, the message of this stepmay merely serve as an acknowledgement to the message.

Then, a new dedicated QoS Flow may be created for the traffic for theapplication for UE 102, which may be based on a selected QoS policyassociated with the application identifier. For creating the dedicatedQoS Flow, SMF 126 may select one of a plurality of QoS policies based onthe application identifier (step 310 of FIG. 3 ). The selected QoSpolicy may be associated with one of a plurality of different 5QIs. Insome implementations, SMF 126 may select the QoS policy based on theapplication identifier by consulting the mapping which is stored inmemory. SMF 126 may perform radio-side messaging for creating thededicated QoS Flow, sending one or more radio-side messages for creatingthe dedicated QoS Flow (step 312 of FIG. 3 ), which extends to UE 102via a base station (e.g. gNB 104) to UPF 106. The one or more messagesmay include an SDF filter for UE 102, which may be generated based onthe flow metadata (e.g. n-tuple flow metadata) and the applicationidentifier.

The radio-side messaging for QoS Flow creation of step 312 is describednow in more detail. SMF 126 may initiate aNamf_Communication_N1N2Message Transfer towards AMF 124 (step “a” ofFIG. 3 ). The message transfer may include a PDU Session ModificationCommand, and for example, the QFI and QoS profile for the new dedicatedQoS Flow. AMF 124 may send to SMF 126 an acknowledgement datanotification (not shown in FIG. 3 ). AMF 124 may then send an N2 PDUSession Request message to gNB 104 (step “b” of FIG. 3 ). This messagemay include an N1 Session Management (SM) container which carries thePDU Session Modification Command. The gNB 104 may issue a signalingexchange with UE 102 that is related with the information received fromSMF 126. Here, an RRC Connection Reconfiguration may take place with UE102 (e.g. transporting the N1 SM container to UE 102) for modifyingresources related to the PDU session (step “c” of FIG. 3 ). The gNB 104may acknowledge the N2 PDU Session Request by sending an N2 PDU SessionAck message to AMF 124 (step “d” of FIG. 3 ). AMF 124 may forward the N2SM information to SMF 126 via an Nsmf_PDUSession_UpdateSMContext serviceoperation (step “e” of FIG. 3 ). SMF 126 may reply with anNsmf_PDUSession_UpdateSMContext Response (step “f” of FIG. 3 ).

With respect to UPF 106, SMF 126 may update the N4 session of UPF 106 bysending an N4 Session Modification Request (step 314 of FIG. 3 ). Thismay be for configuring one or more rules of the selected QoS policy atUPF 106 for the dedicated QoS Flow. For example, SMF 126 may update UPF106 with one or more UL PDRs for the new dedicated QoS Flow. This mayallow UL packets with the QFI of the new QoS Flow to be communicated.UPF 106 may reply with an N4 Session Modification Response (step 316 ofFIG. 3 ).

Continuing with the radio-side messaging after step “f”, UE 102 mayacknowledge the PDU Session Modification Command from step “c” bysending a NAS message to gNB 104 (step “g” of FIG. 3 ), which forwardsthe NAS message to AMF 124 (step “h” of FIG. 3 ). AMF 124 forwards theN1 SM container (e.g. including the PDU Session Modification CommandAck) to SMF 126 via an Nsmf_PDUSession_UpdateSMContext service operation(step “i” of FIG. 3 ). SMF 126 may reply with aNsmf_PDUSession_UpdateSMContext Response (step “j” of FIG. 3 ).

With respect to UPF 106, SMF 126 may again update the N4 session of UPF106 by sending an N4 Session Modification Request (step 318 of FIG. 3 ).UPF 106 may reply with an N4 Session Modification Response (step 320 ofFIG. 3 ).

FIG. 4 is a call flow diagram 400 for describing a call flow for QoSresource management for optimizing use of QoS resources in a mobilenetwork (e.g. the enterprise private 3GPP based network of FIGS. 1A-1B)according to some implementations of the present disclosure. In someimplementations, the call flow of FIG. 4 may be and/or be referred to asa UPF-triggered QoS Flow deletion procedure.

Initially, UPF 106 may operate to forward traffic for an application fora UE in a dedicated QoS Flow. The dedicated QoS Flow may be associatedwith at least one of a GBR, a GFBR, or a PDB. UPF 106 may monitortraffic activity/inactivity in the dedicated QoS Flow. Based on themonitoring, UPF 106 may determine that a measured time period of(continuous) traffic inactivity for the dedicated QoS Flow is outside alimit set by a time period threshold (step 402 of FIG. 4 ). In responseto determining, UPF 106 may send, to SMF 126 based on the determining, amessage which indicates a request for deleting the dedicated QoS Flow(step 404 of FIG. 4 ). The message may include information associatedwith the dedicated QoS Flow for deletion. In some implementations, theinformation associated with the dedicated QoS Flow may include at leastone of a QFI, a CP F-SEID, or a TEID associated with the dedicated QoSFlow. In response to receiving the message of step 404, UPF 106 mayreceive, from SMF 126, a message which indicates a response to thedeleting of the dedicated QoS Flow (step 406 of FIG. 4 ). In someimplementations, the message of step 406 may merely serve as anacknowledgement to the message of step 404.

In response to the message of step 404, SMF 126 may send one or moreradio-side messages for deleting the QoS Flow (step 408 of FIG. 4 ). Insome implementations, this procedure or its steps may involve a standardprocedure for deletion of a QoS Flow. UPF 106 may then receive, from SMF126, a message which indicates a session modification request fordeleting the dedicated QoS Flow (step 410 of FIG. 4 ). Again, SMF 126may issue this request based on the information received in relation therequest for deletion. UPF 106 may then remove the dedicated QoS Flow,which includes deleting the one or more rules for the dedicated QoS Flow(step 412 of FIG. 4 ). For example, the one or more rules to be removedor deleted may include the PDR and/or the FAR. UPF 106 may send, to SMF126, a message which indicates a session modification response (step 414of FIG. 4 ).

With respect to the above procedures in FIGS. 3 and 4 , the procedurefor QoS Flow creation (i.e. the procedure of FIG. 3 ) includes theidentification and use of a single 5-tuple packet filter according to aninitial or first detected packet. However, a QoS Flow may be used formany different IP traffic streams associated with multiple different5-tuples (e.g. multiple IP traffic streams associated with the sameapplication, or even different applications).

Accordingly, what are needed are techniques and mechanisms for packetflow management for existing QoS flows, which may provide for packetflow and filter addition to an existing QoS Flow, as well as packet flowand filter removal from an existing QoS Flow.

FIG. 5 is a flowchart 500 for describing a method of packet flowmanagement for existing QoS Flows in a mobile network, such as anenterprise private 5G network, according to some implementations of thepresent disclosure. In particular, the method of FIG. 5 involves apacket flow and filter addition to an existing QoS Flow according tosome implementations. The method of FIG. 5 may be performed by a userplane function node for use in a mobile network. More particularly, themethod of FIG. 5 may be performed by a network node or computing deviceconfigured to connect in a network for communication, to operate a userplane function. In some implementations, the computing device or networknode may include at least one or more interfaces configured to connectto a network for communication, one or more processors, one or morememory elements coupled to the one or more processors, and instructionsstored in the one or more memory elements. The method may be embodied asa computer program product including a non-transitory computer readablemedium (e.g. one or more memory elements) and instructions stored in thecomputer readable medium, where the instructions are executable on oneor more processors for performing the steps of the method. In someimplementations, the instructions stored in the one or more memoryelements may be executable on the one or more processors for operationas a user plane function, a UPF, or other similar function.

Beginning at a start block 502 of FIG. 5 , the user plane function nodemay receive a packet for traffic associated with a UE (step 504 of FIG.5 ). The user plane function node may identify that a packet filter forthe packet is not found in a packet filter set of an existing QoS Flow(step 506 of FIG. 5 ). Based on the identifying, the user plane functionnode may configure the packet filter in the packet filter set of theexisting QoS Flow based on a flow tuple of the packet (step 508 of FIG.5 ). The packet filter based on the flow tuple may be utilized forpacket classification of a packet flow associated with the UE. In someimplementations, the flow tuple may be an IP tuple or 5-tuple for an IPflow. In addition, the user plane function node may send, to a controlplane function node, a message which indicates a request for adding theflow tuple to the existing QoS Flow (step 510 of FIG. 5 ). The messagemay be used for triggering communication of a message which indicates asession modification command for receipt by the UE, for adding an uplinkpacket filter that is based on the flow tuple for the existing QoS Flow.The message which indicate the request may include the flow tuple of thepacket of the packet flow, a QFI of the existing QoS Flow, and a PDR IDof a PDR associated with the packet filter set. The user plane functionnode may receive, from the control plane function node, a message whichindicates a response to the request for adding the flow tuple to theexisting QoS Flow (step 512 of FIG. 5 ).

In some implementations of step 506, as an alternative to or addition towhen the packet filter for the packet is not found in the packet filterset in step 506, if the user plane function node identifies that packetclassification for the packet is based on an access control list (ACL)or a Differentiated Services Control Point (DSCP) (e.g. for traditionalenterprise QoS/policy control), then the user plane function node mayrefrain from performing steps 508, 510, and 512.

In step 510, where the control plane function node has an SMF (e.g. foruse in a public 5G network), the control plane function node maycommunicate the message which indicates the session modification commandby sending, towards an AMF and to the UE, a message which indicates anN1N2 message transfer, and which includes the message which indicatesthe session modification command for adding the uplink packet filterthat is based on the flow tuple for the existing QoS Flow. Alternativelyin step 510, where the control plane function node has both an SMF andan AMF (e.g. for use in an enterprise private 5G network), the controlplane function node may communicate the message which indicates thesession modification command by sending, towards a RAN to the UE, amessage which indicates the session modification command for adding theuplink packet filter that is based on the flow tuple for the existingQoS Flow.

FIG. 6 is a flowchart 600 for describing a method of packet flowmanagement for existing QoS Flows in a mobile network, such as anenterprise private 5G network, according to some implementations of thepresent disclosure. In particular, the method of FIG. 6 involves apacket flow and filter addition to an existing QoS Flow according tosome implementations. The method of FIG. 6 may be performed by a controlplane function node for use in a mobile network, and is a correspondingmethod to the method of FIG. 5 involving the user plane function node.More particularly, the method of FIG. 6 may be performed by a networknode or computing device configured to connect in a network forcommunication, to operate a control plane function. In someimplementations, the computing device or network node may include atleast one or more interfaces configured to connect to a network forcommunication, one or more processors, one or more memory elementscoupled to the one or more processors, and instructions stored in theone or more memory elements. The method may be embodied as a computerprogram product including a non-transitory computer readable medium(e.g. one or more memory elements) and instructions stored in thecomputer readable medium, where the instructions are executable on oneor more processors for performing the steps of the method. In someimplementations, the instructions stored in the one or more memoryelements may be executable on the one or more processors for operationas a control plane function, an SMF, an SMF plus AMF, or other similarfunction(s).

Beginning at a start block 602 of FIG. 6 , the control plane functionnode may receive, from a user plane function node, a message whichindicates a request for adding a flow tuple to an existing QoS Flow fortraffic associated with a UE (step 604 of FIG. 6 ). This request may bereceived in response to the user plane function node identifying that apacket filter for a detected packet is not found in a packet filter setof an existing QoS Flow. In some implementations, the flow tuple is anIP tuple or 5-tuple for an IP flow. The message may indicate the flowtuple of the detected packet associated with a packet flow, a QFI of theexisting QoS Flow, and a PDR ID of a PDR associated with the packetfilter set. Based on receiving the message which indicates the request,the control plane function node may communicate a message whichindicates a session modification command for receipt by the UE (step 606of FIG. 6 ), for adding an uplink packet filter that is based on theflow tuple for the existing QoS Flow. The control plane function nodemay send, to the user plane function node, a message which indicates aresponse to the request for adding the flow tuple to the existing QoSFlow (step 608 of FIG. 6 ).

In step 604, where the control plane function node has an SMF for use inthe mobile network (e.g. for use in a public 5G network), the controlplane function node may communicate the message which indicates thesession modification command for receipt by the UE by sending, towardsthe AMF and to the UE, a message which indicates an N1N2 messagetransfer, and which includes the message which indicates the sessionmodification command for adding the uplink packet filter that is basedon the flow tuple for the existing QoS Flow. Alternatively in step 604,where the control plane function node has both an SMF and AMF (e.g. foruse in an enterprise private 5G network), the control plane functionnode may communicate the message which indicates the sessionmodification command for receipt by the UE by sending, towards a RAN(e.g. gNB) to the UE, a message which indicates the session modificationcommand for adding the uplink packet filter that is based on the flowtuple for the existing QoS Flow.

FIG. 7 is a call flow diagram 700 for describing a call flow for packetflow management for existing QoS Flows in a mobile network. Inparticular, the call flow of FIG. 7 involves a packet flow and filteraddition to an existing QoS Flow according to some implementations. Thecall flow of FIG. 7 may be in accord with the methods of FIGS. 5-6 .

In FIG. 7 , a dedicated QoS Flow may be established at UPF 106. In someimplementations, the dedicated QoS Flow may be established with use ofthe techniques described in relation to FIG. 3 (i.e. a “UPF-triggeredQoS Flow creation procedure”). Here, a packet filter associated with asingle flow tuple may be utilized for packet classification of thesingle packet flow in the QoS Flow. Subsequently, UPF 106 may receive a“new” stream of traffic for a matching application on the existing QoSFlow (step 702 of FIG. 7 ). Here, UPF 106 may identify that a packetfilter for the packet is not found in a packet filter set of theexisting QoS Flow. Based on the identifying, the user plane functionnode may configure the packet filter in the packet filter set of theexisting QoS Flow based on a flow tuple of the packet. The packet filterbased on the flow tuple may be utilized for packet classification of apacket flow associated with the UE. In some implementations, the flowtuple is an IP tuple or 5-tuple for an IP flow. In addition, UPF 106 maysend, to control plane function 108, a message which indicates a requestfor adding the flow tuple to the existing QoS Flow (step 704 of FIG. 7). The message which indicates the request may include the flow tuple ofthe detected packet, a QFI of the existing QoS Flow, a PDR ID of a PDRassociated with the packet filter set. The message may be used fortriggering communication of a message which indicates a sessionmodification command for receipt by UE 102 (step 706 of FIG. 7 ), foradding an uplink packet filter that is based on the flow tuple for theexisting QoS Flow. In response to receipt of the message, UE 102 mayconfigure the uplink packet filter for packet classification (step 708of FIG. 7 ). UPF 106 may receive, from the control plane function, amessage which indicates a response to the request for adding the flowtuple to the existing QoS Flow (step 710 of FIG. 7 ). In someimplementations of step 702, (even) if the packet filter for the packetis not found in the packet filter set in step 702, and UPF 106identifies that packet classification for the packet is based on an ACLor a DSCP (e.g. for traditional enterprise QoS/policy control), then UPF106 may refrain from performing and triggering the above steps andprocessing (i.e. refrain from steps 508, 510, and 512).

In step 706, where control plane function 108 has both an SMF and an AMF(e.g. for use in an enterprise private 5G network), control planefunction 108 may communicate the message which indicates the sessionmodification command by sending, towards a RAN (e.g. gNB) to the UE 102,a message which indicates the session modification command for addingthe uplink packet filter that is based on the flow tuple for theexisting QoS Flow. Alternatively in step 706, where control planefunction 108 has an SMF (e.g. without AMF functionality) (e.g. for usein a public 5G network), control plane function 108 may communicate themessage which indicates the session modification command by sending,towards an AMF and to the UE 102, a message which indicates an N1N2message transfer, and which includes the message which indicates thesession modification command for adding the uplink packet filter that isbased on the flow tuple for the existing QoS Flow. In someimplementations, radio-side messaging that may be used to achieve theabove processing may be similar to radio-side messaging 312 as describedin relation to FIG. 3 .

FIG. 8 is a table 800 having a list of IEs which may be utilized in amessage which indicates a request for adding a flow tuple to an existingQoS Flow for the methods described in relation to FIGS. 5-7 according tosome implementations. As shown in table 800, the IEs may include (atleast some of) the QFI of the existing QoS Flow, the PDR ID of the PDRassociated with the packet filter set, a protocol type, a source port, adestination port, a source address, and a destination address. Inaddition, FIG. 9 is a table 900 having a list of IEs which may beutilized in a message which indicates a response to the request foradding a flow tuple from an existing QoS Flow for the methods describedin relation to FIGS. 5-7 according to some implementations. As shown intable 900, the IEs may include a cause and an offending IE (e.g. forindicating any issues in syntax, coding).

FIG. 10 is a flowchart 1000 for describing a method of packet flowmanagement for existing QoS Flows in a mobile network, such as anenterprise private 5G network, according to some implementations of thepresent disclosure. In particular, the method of FIG. 10 involves apacket flow and filter removal to an existing QoS Flow according to someimplementations. The method of FIG. 10 may be performed by a user planefunction node for use in a mobile network. More particularly, the methodof FIG. 10 may be performed by a network node or computing deviceconfigured to connect in a network for communication, to operate a userplane function. In some implementations, the computing device or networknode may include at least one or more interfaces configured to connectto a network for communication, one or more processors, one or morememory elements coupled to the one or more processors, and instructionsstored in the one or more memory elements. The method may be embodied asa computer program product including a non-transitory computer readablemedium (e.g. one or more memory elements) and instructions stored in thecomputer readable medium, where the instructions are executable on oneor more processors for performing the steps of the method. In someimplementations, the instructions stored in the one or more memoryelements may be executable on the one or more processors for operationas a user plane function, a UPF, or other similar function.

Initially in FIG. 10 , a dedicated QoS Flow may be established. In someimplementations, this QoS Flow may be established with use of thetechniques described in relation to FIG. 3 (i.e. the UPF-triggered QoSFlow creation procedure), where a plurality of packet filters associatedwith a plurality of flow tuples may be configured for packetclassification for multiple packet flows of the QoS Flow with use of thetechniques described in relation to FIGS. 5-9 .

Beginning at a start block 1002 of FIG. 10 , the user plane functionnode may identify that a limit on a number of packet filters of a packetfilter set of the existing QoS Flow has been reached (step 1004 of FIG.10 ). The limit may be identified when the user plane function nodereceives a “new” stream of traffic for a matching application on theexisting QoS Flow. Alternatively, the user plane function node mayidentify that a measured time period of traffic inactivity for a packetflow of the existing QoS Flow has been reached (alternative step 1004 ofFIG. 10 ). Based on the identifying, the user plane function node mayremove a packet filter in the packet filter set of the existing QoS Flowthat is based on a flow tuple and utilized for packet classification ofthe packet flow (step 1006 of FIG. 10 ). In some implementations, thepacket filter that is selected for removal may be one that is identifiedto be inactive or least active relative to most or all other packetfilters/flows. In some implementations, the flow tuple is an IP tuple or5-tuple for an IP flow. The user plane function node may send, to thecontrol plane function node, a message which indicates a request forremoving the flow tuple from the existing QoS Flow (step 1008 of FIG. 10). The message may be for triggering communication of a message whichindicates a session modification command for receipt by the UE, forremoval of an uplink packet filter that is based on the flow tuple ofthe existing QoS Flow. The message which indicates the request mayinclude the flow tuple of the packet flow, a QFI of the existing QoSFlow, and a PDR ID of a PDR associated with the packet filter set. Theuser plane function node may receive, from the control plane functionnode, a message which indicates a response to the request for removingthe flow tuple from the existing QoS Flow (step 1010 of FIG. 10 ).

FIG. 11 is a flowchart 1100 for describing a method of packet flowmanagement for existing QoS Flows in a mobile network, such as anenterprise private 5G network, according to some implementations of thepresent disclosure. In particular, the method of FIG. 11 involves apacket flow and filter removal from an existing QoS Flow according tosome implementations. The method of FIG. 11 may be performed by acontrol plane function node for use in a mobile network, and is acorresponding method to the method of FIG. 10 involving the user planefunction node. More particularly, the method of FIG. 11 may be performedby a network node or computing device configured to connect in a networkfor communication, to operate a control plane function. In someimplementations, the computing device or network node may include atleast one or more interfaces configured to connect to a network forcommunication, one or more processors, one or more memory elementscoupled to the one or more processors, and instructions stored in theone or more memory elements. The method may be embodied as a computerprogram product including a non-transitory computer readable medium(e.g. one or more memory elements) and instructions stored in thecomputer readable medium, where the instructions are executable on oneor more processors for performing the steps of the method. In someimplementations, the instructions stored in the one or more memoryelements may be executable on the one or more processors for operationas a control plane function, an SMF, an SMF plus an AMF, or othersimilar function(s).

Initially in FIG. 11 , a dedicated QoS Flow may be established. In someimplementations, this QoS Flow may be established with use of thetechniques described in relation to FIG. 3 (i.e. the UPF-triggered QoSFlow creation procedure), where a plurality of packet filters associatedwith a plurality of flow tuples may be configured for packetclassification for multiple packet flows of the QoS Flow with use of thetechniques described in relation to FIGS. 5-9 .

Beginning at a start block 1102 of FIG. 11 , the control plane functionnode may receive, from the user plane function node, a message whichindicates a request for removing a flow tuple from the existing QoS Flow(step 1104 of FIG. 11 ). This request may be received in response to theuser plane function node identifying that a limit on a number of packetfilters of a packet filter set of the existing QoS Flow has beenreached, for example, when the user plane function node receives a “new”stream of traffic for a matching application on the existing QoS Flow.In some implementations, the packet filter that is selected for removalmay be one that is identified to be inactive or least active relative tomost or all other packet filters/flows. Alternatively, this request maybe received in response to that a measured time period of trafficinactivity for a packet flow of the existing QoS Flow has been reached.In some implementations, the flow tuple is an IP tuple or 5-tuple for anIP flow. The message may indicate the flow tuple associated with apacket flow, the QFI of the existing QoS Flow, and a PDR ID of a PDRassociated with a packet filter set of the existing QoS Flow. Based onreceiving the message which indicates the request, the control planefunction node may communicate a message which indicates a sessionmodification command for receipt by the UE (step 1106 of FIG. 11 ), forremoval of an uplink packet filter that is based on the flow tuple forthe existing QoS Flow. The control plane function node may send, to theuser plane function node, a message which indicates a response to therequest for removing the flow tuple from the existing QoS Flow (step1108 of FIG. 11 ).

FIG. 12 is a call flow diagram 1200 for describing a call flow forpacket flow management for existing QoS Flows in a mobile network. Inparticular, the call flow of FIG. 7 involves a packet flow and filterremoval from an existing QoS Flow according to some implementations. Thecall flow of FIG. 12 may be in accord with the methods of FIGS. 10-11 .

Initially in FIG. 12 , a dedicated QoS Flow may be established at UPF106. In some implementations, the dedicated QoS Flow may be establishedwith use of the techniques described in relation to FIG. 3 (i.e. theUPF-triggered QoS Flow creation procedure), where a plurality of packetfilters associated with a plurality of flow tuples may be configured forpacket classification for multiple packet flows of the QoS Flow with useof the techniques described in relation to FIGS. 5-9 .

Sometime during operation, UPF 106 may receive a new stream of trafficfor a matching application on the QoS Flow, but identify that a limit ona number of packet filters of the packet filter set of the existing QoSFlow has been reached (step 1202 of FIG. 12 ). Alternatively, UPF 106may identify that a measured time period of traffic inactivity for apacket flow of the existing QoS Flow has been reached (alternative step1202 of FIG. 10 ). Based on the identifying, UPF 106 may remove a packetfilter in the packet filter set of the existing QoS Flow that is basedon a flow tuple and utilized for packet classification of the packetflow. In some implementations, the flow tuple is an IP tuple or 5-tuplefor an IP flow. UPF 106 may send, to control plane function 108, amessage which indicates a request for removing the flow tuple from theexisting QoS Flow (step 1204 of FIG. 12 ). The message may be fortriggering communication of a message which indicates a sessionmodification command for receipt by UE 102 (step 1206 of FIG. 12 ), forremoval of an uplink packet filter that is based on the flow tuple ofthe existing QoS Flow. The message may indicate the flow tupleassociated with a packet flow, the QFI of the existing QoS Flow, and aPDR ID of a PDR associated with a packet filter set of the existing QoSFlow. In some implementations, the packet filter that is selected forremoval may be one that is identified to be inactive or least activerelative to most or all other packet filters/flows. In response toreceipt of the message, UE 102 may configure the uplink packet filterfor packet classification (step 1208 of FIG. 12 ). UPF 106 may receive,from control plane function 108, a message which indicates a response tothe request for removing the flow tuple from the existing QoS Flow (step1210 of FIG. 12 ).

In step 1206, where control plane function 108 has both an SMF and anAMF (e.g. for use in an enterprise private 5G network), control planefunction 108 may communicate the message which indicates the sessionmodification command by sending, towards a RAN (e.g. gNB) to UE 102, amessage which indicates the session modification command for removingthe uplink packet filter that is based on the flow tuple for theexisting QoS Flow. Alternatively in step 1206, where control planefunction 108 has an SMF (e.g. without AMF functionality) (e.g. for usein a public 5G network), control plane function 108 may communicate themessage which indicates the session modification command by sending,towards an AMF and to UE 102, a message which indicates an N1N2 messagetransfer, and which includes the message which indicates the sessionmodification command for adding the uplink packet filter that is basedon the flow tuple for the existing QoS Flow. In some implementations,radio-side messaging that may be used to achieve the above processingmay be similar to radio-side messaging 312 as described in relation toFIG. 3 .

FIG. 13 is a table 1300 having a list of IEs which may be utilized in amessage which indicates a request for removing a flow tuple to anexisting QoS Flow for the methods described in relation to FIGS. 10-12according to some implementations. As shown in table 1300, the IEs mayinclude (at least some of) the QFI of the existing QoS Flow, the PDR IDof the PDR associated with the packet filter set, a protocol type, asource port, a destination port, a source address, and a destinationaddress. In addition, FIG. 14 is a table 1400 having a list of IEs whichmay be utilized in a message which indicates a response to the requestfor removing a flow tuple from an existing QoS Flow for the methodsdescribed in relation to FIGS. 10-12 according to some implementations.As shown in table 1400, the IEs may include a cause and an offending IE(e.g. for indicating any issues in syntax, coding).

Accordingly, once a QoS Flow is established with use of theUPF-triggered QoS Flow creation procedure (e.g. FIG. 3 ), any new packetflows may be added upon receipt of new traffic associated with the QoSFlow in accordance with FIGS. 5-9 ; packet flows may be removed upondetection of an excess number of packet flows and/or flow inactivitytimeouts in accordance with FIGS. 10-14 . Eventually, the QoS Flow maybe deleted with use of the UPF-triggered QoS Flow deletion procedure(e.g. FIG. 4 ).

FIG. 15 illustrates a hardware block diagram of a computing device 1500that may perform functions associated with operations discussed hereinin connection with the techniques described in relation to the abovefigures, especially in relation to FIGS. 5-9 and 10-14 , and includingFIGS. 3-4 . In various embodiments, a computing device, such ascomputing device 1500 or any combination of computing devices 1500, maybe configured as any entity/entities as discussed for the techniquesdepicted in connection with the figures in order to perform operationsof the various techniques discussed herein.

In at least one embodiment, the computing device 1500 may include one ormore processor(s) 1502, one or more memory element(s) 1504, storage1506, a bus 1508, one or more network processor unit(s) 1510interconnected with one or more network input/output (I/O) interface(s)1512, one or more I/O interface(s) 1514, and control logic 1520. Invarious embodiments, instructions associated with logic for computingdevice 1500 can overlap in any manner and are not limited to thespecific allocation of instructions and/or operations described herein.

In at least one embodiment, processor(s) 1502 is/are at least onehardware processor configured to execute various tasks, operationsand/or functions for computing device 1500 as described herein accordingto software and/or instructions configured for computing device 1500.Processor(s) 1502 (e.g., a hardware processor) can execute any type ofinstructions associated with data to achieve the operations detailedherein. In one example, processor(s) 1502 can transform an element or anarticle (e.g., data, information) from one state or thing to anotherstate or thing. Any of potential processing elements, microprocessors,digital signal processor, baseband signal processor, modem, PHY,controllers, systems, managers, logic, and/or machines described hereincan be construed as being encompassed within the broad term ‘processor’.

In at least one embodiment, memory element(s) 1504 and/or storage 1506is/are configured to store data, information, software, and/orinstructions associated with computing device 1500, and/or logicconfigured for memory element(s) 1504 and/or storage 1506. For example,any logic described herein (e.g., control logic 1520) can, in variousembodiments, be stored for computing device 1500 using any combinationof memory element(s) 1504 and/or storage 1506. Note that in someembodiments, storage 1506 can be consolidated with memory element(s)1504 (or vice versa), or can overlap/exist in any other suitable manner.

In at least one embodiment, bus 1508 can be configured as an interfacethat enables one or more elements of computing device 1500 tocommunicate in order to exchange information and/or data. Bus 1508 canbe implemented with any architecture designed for passing control, dataand/or information between processors, memory elements/storage,peripheral devices, and/or any other hardware and/or software componentsthat may be configured for computing device 1500. In at least oneembodiment, bus 1508 may be implemented as a fast kernel-hostedinterconnect, potentially using shared memory between processes (e.g.,logic), which can enable efficient communication paths between theprocesses.

In various embodiments, network processor unit(s) 1510 may enablecommunication between computing device 1500 and other systems, entities,etc., via network I/O interface(s) 1512 to facilitate operationsdiscussed for various embodiments described herein. In variousembodiments, network processor unit(s) 1510 can be configured as acombination of hardware and/or software, such as one or more Ethernetdriver(s) and/or controller(s) or interface cards, Fibre Channel (e.g.,optical) driver(s) and/or controller(s), and/or other similar networkinterface driver(s) and/or controller(s) now known or hereafterdeveloped to enable communications between computing device 1500 andother systems, entities, etc. to facilitate operations for variousembodiments described herein. In various embodiments, network I/Ointerface(s) 1512 can be configured as one or more Ethernet port(s),Fibre Channel ports, and/or any other I/O port(s) now known or hereafterdeveloped. Thus, the network processor unit(s) 1510 and/or network I/Ointerface(s) 1512 may include suitable interfaces for receiving,transmitting, and/or otherwise communicating data and/or information ina network environment.

I/O interface(s) 1514 allow for input and output of data and/orinformation with other entities that may be connected to computer device1500. For example, I/O interface(s) 1514 may provide a connection toexternal devices such as a keyboard, keypad, a touch screen, and/or anyother suitable input and/or output device now known or hereafterdeveloped. In some instances, external devices can also include portablecomputer readable (non-transitory) storage media such as databasesystems, thumb drives, portable optical or magnetic disks, and memorycards. In still some instances, external devices can be a mechanism todisplay data to a user, such as, for example, a computer monitor, adisplay screen, or the like.

In various embodiments, control logic 1520 can include instructionsthat, when executed, cause processor(s) 1502 to perform operations,which can include, but not be limited to, providing overall controloperations of computing device; interacting with other entities,systems, etc. described herein; maintaining and/or interacting withstored data, information, parameters, etc. (e.g., memory element(s),storage, data structures, databases, tables, etc.); combinationsthereof; and/or the like to facilitate various operations forembodiments described herein.

The programs described herein (e.g., control logic 1520) may beidentified based upon application(s) for which they are implemented in aspecific embodiment. However, it should be appreciated that anyparticular program nomenclature herein is used merely for convenience;thus, embodiments herein should not be limited to use(s) solelydescribed in any specific application(s) identified and/or implied bysuch nomenclature.

In various embodiments, entities as described herein may storedata/information in any suitable volatile and/or non-volatile memoryitem (e.g., magnetic hard disk drive, solid state hard drive,semiconductor storage device, random access memory (RAM), read onlymemory (ROM), erasable programmable read only memory (EPROM),application specific integrated circuit (ASIC), etc.), software, logic(fixed logic, hardware logic, programmable logic, analog logic, digitallogic), hardware, and/or in any other suitable component, device,element, and/or object as may be appropriate. Any of the memory itemsdiscussed herein should be construed as being encompassed within thebroad term ‘memory element’. Data/information being tracked and/or sentto one or more entities as discussed herein could be provided in anydatabase, table, register, list, cache, storage, and/or storagestructure: all of which can be referenced at any suitable timeframe. Anysuch storage options may also be included within the broad term ‘memoryelement’ as used herein.

Note that in certain example implementations, operations as set forthherein may be implemented by logic encoded in one or more tangible mediathat is capable of storing instructions and/or digital information andmay be inclusive of non-transitory tangible media and/or non-transitorycomputer readable storage media (e.g., embedded logic provided in: anASIC, digital signal processing (DSP) instructions, software[potentially inclusive of object code and source code], etc.) forexecution by one or more processor(s), and/or other similar machine,etc. Generally, memory element(s) 1504 and/or storage 1506 can storedata, software, code, instructions (e.g., processor instructions),logic, parameters, combinations thereof, and/or the like used foroperations described herein. This includes memory element(s) 1504 and/orstorage 1506 being able to store data, software, code, instructions(e.g., processor instructions), logic, parameters, combinations thereof,or the like that are executed to carry out operations in accordance withteachings of the present disclosure.

In some instances, software of the present embodiments may be availablevia a non-transitory computer useable medium (e.g., magnetic or opticalmediums, magneto-optic mediums, CD-ROM, DVD, memory devices, etc.) of astationary or portable program product apparatus, downloadable file(s),file wrapper(s), object(s), package(s), container(s), and/or the like.In some instances, non-transitory computer readable storage media mayalso be removable. For example, a removable hard drive may be used formemory/storage in some implementations. Other examples may includeoptical and magnetic disks, thumb drives, and smart cards that can beinserted and/or otherwise connected to a computing device for transferonto another computer readable storage medium.

Variations and Implementations

Embodiments described herein may include one or more networks, which canrepresent a series of points and/or network elements of interconnectedcommunication paths for receiving and/or transmitting messages (e.g.,packets of information) that propagate through the one or more networks.These network elements offer communicative interfaces that facilitatecommunications between the network elements. A network can include anynumber of hardware and/or software elements coupled to (and incommunication with) each other through a communication medium. Suchnetworks can include, but are not limited to, any local area network(LAN), virtual LAN (VLAN), wide area network (WAN) (e.g., the Internet),software defined WAN (SD-WAN), wireless local area (WLA) access network,wireless wide area (WWA) access network, metropolitan area network(MAN), Intranet, Extranet, virtual private network (VPN), Low PowerNetwork (LPN), Low Power Wide Area Network (LPWAN), Machine to Machine(M2M) network, Internet of Things (IoT) network, Ethernetnetwork/switching system, any other appropriate architecture and/orsystem that facilitates communications in a network environment, and/orany suitable combination thereof.

Networks through which communications propagate can use any suitabletechnologies for communications including wireless communications (e.g.,4G/5G/nG, IEEE 802.11 (e.g., Wi-Fi®/Wi-Fi6®), IEEE 802.16 (e.g.,Worldwide Interoperability for Microwave Access (WiMAX)),Radio-Frequency Identification (RFID), Near Field Communication (NFC),Bluetooth™, mm.wave, Ultra-Wideband (UWB), etc.), and/or wiredcommunications (e.g., T1 lines, T3 lines, digital subscriber lines(DSL), Ethernet, Fibre Channel, etc.). Generally, any suitable means ofcommunications may be used such as electric, sound, light, infrared,and/or radio to facilitate communications through one or more networksin accordance with embodiments herein. Communications, interactions,operations, etc. as discussed for various embodiments described hereinmay be performed among entities that may directly or indirectlyconnected utilizing any algorithms, communication protocols, interfaces,etc. (proprietary and/or non-proprietary) that allow for the exchange ofdata and/or information.

In various example implementations, entities for various embodimentsdescribed herein can encompass network elements (which can includevirtualized network elements, functions, etc.) such as, for example,network appliances, forwarders, routers, servers, switches, gateways,bridges, loadbalancers, firewalls, processors, modules, radioreceivers/transmitters, or any other suitable device, component,element, or object operable to exchange information that facilitates orotherwise helps to facilitate various operations in a networkenvironment as described for various embodiments herein. Note that withthe examples provided herein, interaction may be described in terms ofone, two, three, or four entities. However, this has been done forpurposes of clarity, simplicity and example only. The examples providedshould not limit the scope or inhibit the broad teachings of systems,networks, etc. described herein as potentially applied to a myriad ofother architectures.

Communications in a network environment can be referred to herein as‘messages’, ‘messaging’, ‘signaling’, ‘data’, ‘content’, ‘objects’,‘requests’, ‘queries’, ‘responses’, ‘replies’, etc. which may beinclusive of packets. As referred to herein and in the claims, the term‘packet’ may be used in a generic sense to include packets, frames,segments, datagrams, and/or any other generic units that may be used totransmit communications in a network environment. Generally, a packet isa formatted unit of data that can contain control or routing information(e.g., source and destination address, source and destination port,etc.) and data, which is also sometimes referred to as a ‘payload’,‘data payload’, and variations thereof. In some embodiments, control orrouting information, management information, or the like can be includedin packet fields, such as within header(s) and/or trailer(s) of packets.IP addresses discussed herein and in the claims can include any IPversion 4 (IPv4) and/or IP version 6 (IPv6) addresses.

To the extent that embodiments presented herein relate to the storage ofdata, the embodiments may employ any number of any conventional or otherdatabases, data stores or storage structures (e.g., files, databases,data structures, data or other repositories, etc.) to store information.

Note that in this Specification, references to various features (e.g.,elements, structures, nodes, modules, components, engines, logic, steps,operations, functions, characteristics, etc.) included in ‘oneembodiment’, ‘example embodiment’, ‘an embodiment’, ‘anotherembodiment’, ‘certain embodiments’, ‘some embodiments’, ‘variousembodiments’, ‘other embodiments’, ‘alternative embodiment’, and thelike are intended to mean that any such features are included in one ormore embodiments of the present disclosure, but may or may notnecessarily be combined in the same embodiments. Note also that amodule, engine, client, controller, function, logic or the like as usedherein in this Specification, can be inclusive of an executable filecomprising instructions that can be understood and processed on aserver, computer, processor, machine, compute node, combinationsthereof, or the like and may further include library modules loadedduring execution, object files, system files, hardware logic, softwarelogic, or any other executable modules.

It is also noted that the operations and steps described with referenceto the preceding figures illustrate only some of the possible scenariosthat may be executed by one or more entities discussed herein. Some ofthese operations may be deleted or removed where appropriate, or thesesteps may be modified or changed considerably without departing from thescope of the presented concepts. In addition, the timing and sequence ofthese operations may be altered considerably and still achieve theresults taught in this disclosure. The preceding operational flows havebeen offered for purposes of example and discussion. Substantialflexibility is provided by the embodiments in that any suitablearrangements, chronologies, configurations, and timing mechanisms may beprovided without departing from the teachings of the discussed concepts.

As used herein, unless expressly stated to the contrary, use of thephrase ‘at least one of’, ‘one or more of’, ‘and/or’, variationsthereof, or the like are open-ended expressions that are bothconjunctive and disjunctive in operation for any and all possiblecombination of the associated listed items. For example, each of theexpressions ‘at least one of X, Y and Z’, ‘at least one of X, Y or Z’,‘one or more of X, Y and Z’, ‘one or more of X, Y or Z’ and ‘X, Y and/orZ’ can mean any of the following: 1) X, but not Y and not Z; 2) Y, butnot X and not Z; 3) Z, but not X and not Y; 4) X and Y, but not Z; 5) Xand Z, but not Y; 6) Y and Z, but not X; or 7) X, Y, and Z.

Additionally, unless expressly stated to the contrary, the terms‘first’, ‘second’, ‘third’, etc., are intended to distinguish theparticular nouns they modify (e.g., element, condition, node, module,activity, operation, etc.). Unless expressly stated to the contrary, theuse of these terms is not intended to indicate any type of order, rank,importance, temporal sequence, or hierarchy of the modified noun. Forexample, ‘first X’ and ‘second X’ are intended to designate two ‘X’elements that are not necessarily limited by any order, rank,importance, temporal sequence, or hierarchy of the two elements. Furtheras referred to herein, ‘at least one of’ and ‘one or more of can berepresented using the’(s)′ nomenclature (e.g., one or more element(s)).

One or more advantages described herein are not meant to suggest thatany one of the embodiments described herein necessarily provides all ofthe described advantages or that all the embodiments of the presentdisclosure necessarily provide any one of the described advantages.Numerous other changes, substitutions, variations, alterations, and/ormodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and/or modifications as fallingwithin the scope of the appended claims.

1. A method comprising: at a user plane function node for use in a mobile network, receiving a packet for traffic associated with a user equipment (UE); and identifying that a limit on a number of packet filters of a packet filter set of an existing Quality of Service (QoS) Flow has been reached or that a measured time period of inactivity for a packet flow of the existing QoS Flow has been reached, and based on the identifying: removing a packet filter in the packet filter set of the existing QoS Flow that is based on a flow tuple of the packet and utilized for packet classification of the packet flow associated with the UE; and sending, to a control plane function node, a message which indicates a request for removing the flow tuple from the existing QoS Flow, wherein the request triggers the control plane function node to communicate a second message which indicates a session modification command for receipt by the UE that causes the UE to remove an uplink packet filter that is based on the flow tuple for the existing QoS Flow.
 2. The method of claim 1, further comprising: at the user plane function node, receiving, from the control plane function node, a message which indicates a response to the request for removing the flow tuple from the existing QoS Flow.
 3. The method of claim 1, wherein the message which indicates the request for removing the flow tuple from the existing QoS Flow includes the flow tuple of the packet associated with the packet flow, a QoS Flow Identifier (QFI) of the existing QoS Flow, and a Packet Detection Rule Identifier (PDR ID) of a PDR associated with the packet filter set.
 4. The method of claim 2, wherein the packet flow comprises a first packet flow, the flow tuple comprises a first flow tuple, the packet filter comprises a first packet filter, and the session modification command comprises a first session modification command, the method further comprising: at the user plane function node, identifying that a second packet filter for a second packet associated with the UE is not found in the packet filter set of the existing QoS Flow, and based on the identifying: configuring the second packet filter in the packet filter set of the existing QoS Flow based on a second flow tuple of the second packet, for packet classification of a second packet flow associated with the UE; sending, to the control plane function node, a message which indicates a request for adding the second flow tuple to the existing QoS Flow, for triggering communication of wherein the request triggers the control plane function node to communicate a message which indicates a second session modification command for receipt by the UE that causes the UE to add a second uplink packet filter that is based on the second flow tuple of the existing QoS Flow; and receiving, from the control plane function node, a message which indicates a response to the request for adding the second flow tuple to the existing QoS Flow.
 5. The method of claim 4, wherein the message which indicates the request for adding the second flow tuple to the existing QoS Flow includes the second flow tuple associated with the second packet flow, a QoS Flow Identifier (QFI) of the existing QoS Flow, and a Packet Detection Rule (PDR) ID of a PDR associated with the packet filter set.
 6. The method of claim 1, further comprising: at the user plane function node, identifying that packet classification for the packet is based on an access control list (ACL) or a Differentiated Services Control Point (DSCP), and based on the identifying: refraining from sending, to the control plane function node, the message which indicates the request for removing the flow tuple from the existing QoS Flow.
 7. The method of claim 1, wherein: the control plane function node comprises a session management function (SMF) for use in the mobile network comprising a Third Generation Partnership Project (3GPP) Fifth Generation (5G) network, and the communication of the message which indicates the session modification command by the control plane function node further comprises: sending, towards an access and mobility management function (AMF) and to the UE, a message which indicates an N1N2 message transfer, and which includes the message which indicates the session modification command for removing the uplink packet filter that is based on the flow tuple for the existing QoS Flow, or the control plane function node comprises the SMF and the AMF for use in the mobile network comprising an enterprise private 3GPP 5G network, and the communication of the message which indicates the session modification command by the control plane function node further comprises: sending, towards a radio access network (RAN) to the UE, a message which indicates the session modification command for removing the uplink packet filter that is based on the flow tuple for the existing QoS Flow.
 8. A method comprising: at a control plane function node for use in a mobile network, receiving, from a user plane function node, a message which indicates a request for removing a flow tuple from an existing Quality of Service (QoS) Flow for traffic associated with a user equipment (UE), the message indicating the flow tuple of a detected packet associated with a packet flow and a QoS Flow Identifier (QFI) of the existing QoS Flow; and based on receiving the message which indicates the request for removing the flow tuple from the existing QoS Flow, communicating a second message which indicates a session modification command for receipt by the UE that causes the UE to remove an uplink packet filter that is based on the flow tuple for the existing QoS Flow.
 9. The method of claim 8, further comprising: at the control plane function node, sending, to the user plane function node, a message which indicates a response to the request for removing the flow tuple from the existing QoS Flow.
 10. The method of claim 8, wherein the message which indicates the request for removing the flow tuple from the existing QoS Flow further indicates a Packet Detection Rule Identifier (PDR ID) of a PDR associated with a packet filter set of the existing QoS Flow.
 11. The method of claim 8, wherein the packet flow comprises a first packet flow, the flow tuple comprises a first flow tuple, the uplink packet filter comprises a first uplink packet filter, and the session modification command comprises a first session modification command, the method further comprising: at the control plane function node, receiving, from the user plane function node, a message which indicates a request for adding a second flow tuple to the existing QoS Flow, the message indicating the second flow tuple associated with a second packet flow and the QFI of the existing QoS Flow; based on receiving the message which indicates the request for removing adding the second flow tuple to the existing QoS Flow, communicating a message which indicates a second session modification command for receipt by the UE that causes the UE to add a second uplink packet filter that is based on the second flow tuple for the existing QoS Flow; and sending, to the user plane function node, a message which indicates a response to the request for adding the second flow tuple to the existing QoS Flow.
 12. The method of claim 11, wherein the message which indicates the request for adding the second flow tuple to the existing QoS Flow further includes a Packet Detection Rule (PDR) ID of a PDR associated with a packet filter set of the existing QoS Flow.
 13. The method of claim 8, wherein the control plane function node comprises a session management function (SMF) for use in the mobile network comprising a Third Generation Partnership Project (3GPP) Fifth Generation (5G) network, and wherein communicating the message which indicates the session modification command for receipt by the UE further comprises: sending, towards an access and mobility management function (AMF) and to the UE, a message which indicates an N1N2 message transfer, and which includes the message which indicates the session modification command for removing the uplink packet filter that is based on the flow tuple for the existing QoS Flow.
 14. The method of claim 8, wherein the control plane function node comprises a session management function (SMF) and an access and mobility management function (AMF) for use in the mobile network comprising an enterprise private Third Generation Partnership Project (3GPP) Fifth Generation (5G) network, and wherein communicating the message which indicates the session modification command for receipt by the UE further comprises: sending, towards a radio access network (RAN) to the UE, a message which indicates the session modification command for removing the uplink packet filter that is based on the flow tuple for the existing QoS Flow.
 15. A network node comprising: one or more interfaces to connect in a mobile network; one or more processors; and one or more memory elements for storing instructions executable on the one or more processors for operation as a control plane function of the mobile network, the operation including: receiving, from a user plane function node, a message which indicates a request for removing a flow tuple from an existing Quality of Service (QoS) Flow for traffic associated with a user equipment (UE), the message indicating the flow tuple of a detected packet associated with a packet flow and a QoS Flow Identifier (QFI) of the existing QoS Flow; based on receiving the message which indicates the request for removing the flow tuple from the existing QoS Flow, communicating a second message which indicates a session modification command for receipt by the UE that causes the UE to remove an uplink packet filter that is based on the flow tuple for the existing QoS Flow; and sending, to the user plane function node, a third message which indicates a response to the request for removing the flow tuple from the existing QoS Flow.
 16. The network node of claim 15, wherein the message which indicates the request for removing the flow tuple from the existing QoS Flow further indicates a Packet Detection Rule Identifier (PDR ID) of a PDR associated with a packet filter set of the existing QoS Flow.
 17. The network node of claim 15, wherein the packet flow comprises a first packet flow, the flow tuple comprises a first flow tuple, the uplink packet filter comprises a first uplink packet filter, and the session modification command comprises a first session modification command, and wherein the instructions are executable on the one or more processors for operation as the control plane function further including: receiving, from the user plane function node, a message which indicates a request for adding a second flow tuple to the existing QoS Flow, the message indicating the second flow tuple associated with a second packet flow and the QFI of the existing QoS Flow; based on receiving the message which indicates the request for adding the second flow tuple to the existing QoS Flow, communicating a message which indicates a second session modification command for receipt by the UE that causes the UE to add a second uplink packet filter that is based on the second flow tuple for the existing QoS Flow; and sending, to the user plane function node, a message which indicates a response to the request for adding the second flow tuple to the existing QoS Flow.
 18. The network node of claim 17, wherein the message which indicates the request for adding the second flow tuple to the existing QoS Flow further includes a Packet Detection Rule (PDR) ID of a PDR associated with a packet filter set of the existing QoS Flow.
 19. The network node of claim 15, wherein the control plane function comprises a session management function (SMF) for use in the mobile network comprising a Third Generation Partnership Project (3GPP) Fifth Generation (5G) network, and wherein the instructions are executable on the one or more processors for operation as the control plane function for communicating the message which indicates the session modification command for receipt by the UE by: sending, towards an access and mobility management function (AMF) and to the UE, a message which indicates an N1N2 message transfer, and which includes the message which indicates the session modification command for removing the uplink packet filter that is based on the flow tuple for the existing QoS Flow.
 20. The network node of claim 15, wherein the control plane function comprises a session management function (SMF) and an access and mobility management function (AMF) for use in the mobile network comprising an enterprise private Third Generation Partnership Project (3GPP) Fifth Generation (5G) network, and wherein the instructions are executable on the one or more processors for operation as the control plane function for communicating the message which indicates the session modification command for receipt by the UE by: sending, towards a radio access network (RAN) to the UE, the message which indicates the session modification command for removing the uplink packet filter that is based on the flow tuple for the existing QoS Flow. 